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be used in tne SPLICE (Stock Point Logistics Integrated 
Communication Environment) project. ee examines the 
functional requirements of session services, tne data 
necessary to provide that functionality, and the interfaces 
required. These areas typlcally focus on tne SPLICE 
application specifically, but apply to a generic session 
services as well. 

The recommendations that are offered relate 
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prospect of placing a fault tolerant capability in session 
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Ps INTRODUCTION 

Navy stock points and inventory control points (ICPs) 
are currently in a situation which suggests tnat tney are 
outgrowing their current data processing capabilities. The 
Current hardware suite consists of medium sized Burroughs Bb- 
3500/3780/4700/4806 Systems and 1S becoming saturated by a 
seemingly endless demand for more support. Eacn year, at an 
annual users' conference, the list of “things to do" grows 
longer. Eacn stock point iS autonomous witn respect to how 
it implements data processing support, as long as it 
accommodates the Navy Supply Systems Command (NAVSUP) 
requirements. AS a result, various mini and micro computers 
at these facilities have used locally-provided code instead 
of the standard code provided by the Fleet Material Support 
Office (FMSO) for the FMSO-maintained systems. FMSO has a 
charter to provide system software and application software 
for the existing data processing systems used at_= stock 
points. This system is called the Uniform Automated Data 
Processing System - Stock Points (UADPS-SP). 

Long range plans to overcome the current situation 
include the purchase of new hardware for the stock points 
and ICPs. This effort has resulted in a contract with Tandem 
Computer, Inc. to provide necessary hardware. The design 
framework in which this hardware is to be utilized 1S a 
distributed Local Area Network (LAN) architecture. It has 
been given the name of Stock Point Logistics Integrated 
Communications Environment (SPLICE). 
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SPLICE is designed to augment the existing data 
processing environment at stock points. UADPS-SP, which runs 
on the Burroughs Systems mentioned above, is only one of the 
automated systems at most stock points. There iS _ the 
Integrated Disbursement and Accounting (IDA) System which is 
operating on the Interdata 7/32, the Automated Procurement 
and Data Entry (APADE) System, and the Trident Logistics 
Data System (Trident LDS). Each has its own data elements, 
files, programs, transactions, users, reports, and some have 
additional hardware. To augment them all and not force 
redesign to existing systems is a difficult task. By the 
time that SPLICE is ready to be implemented, there will 
surely be more syStems with whicn to interface. 

Many of the new application requirements involve 
interactive capabilities and telecommunications support. 
This, in general, 1S not supportable with the current mix of 
nardware and software. 

The two advertised major objectives of SPLICE are: (1) 
to allow for CRT display terminals to interact with 
application logic and to fetch information from a_e system 
data base; and, (2) to provide a standard interface for each 
of the sixty-two supported supply sites. Notice that these 
goals are stated in data processing rather than functional 
terms. 

The implementation, in general, is envisioned as having 
mini-computers used as front-ends to the existing hardware. 
The interfaces with existing systems will be controlled by 
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tne LAN. Tne Burroughs systems would be able to provide 


larger file processing functions and report generation 
functions in a background mode. Eacn LAN is planned to be 
"standardized," and have the capability to communicate with 
other LANS via tne Defense Data Network (DIN) eee ee fees 
managed by the Defense Communications Agency. 

Tne functional objects wnich are contained in the 
SPLICE network have been identified at a high level of 
aeeeractlon (Scnneidewind and Dolk, Nov 1983), and major 
functions have been identified for those objects. It is the 
Purpose of this paper to decompose tne object called Session 
Services into lower levels of abstraction, and to clarify 
the functions at a level which should feed the design of the 
actual module. 

A session can be described as all of the activity which 
takes place among two or more processes for the duration of 
a single task. The Session Services module is the object 
which functions as the liaison between the user and required 
functional modules. When the user specifies a required task, 
tne session services object will initiate and control the 
required functional modules to accomplish tne requested 
task, and return the response and the control to the user. 
This control mechanism is a complex one, primarily due to 
the following constraints: 


o A user process may have multiple sessions active at 
any time. 


Oo A functional module can be active in multiple 
sessions at a time. 


o Two or more functional modules can be active wan 
multiple sessions at any tlme. 


o Message excaange between pairs of FUNCE) Omen 
modules can be nested. 


The multi-tasking requirements above are in addition to 
message exchanges petween local and remote sites, and tasxs 
may be elther deferrable or interactive. 

This complex processing environment requires tnat a 
module exist to control this activity. This role has beeq 
delegated to the Session Services Module. 

To more fully comprenend the role of Session Services 
it may be helpful to examine the layers of control found in 


a network architecture, of which Session Services is a 


member. 


Pe wince RCH I TECTURE LEVELS 


A fundamental goal of the SPLICE network arcnitecture 
1S to permit system designs that support @-O0dracaire 
Sesterloutc1On of workstations which reflect the natural 
Dartitloning (bacnman, ee Of tne Navy acini les 
involved. All application programs must be independent from 
the physical topology of tne nodes where tney reside. The 
Session services Layer Supports this independence. 
Workstation programS are written to request session 
establishmentS among them uSing only logical addressing 
names (mailboxes) whicn are independent’ from physical 
topology. Tnese requests are all sent to Session Services. 
The session services module employs two principal mecnanisms 
(Bachman, 1978). The first mecnanism 1S that it links 
processes into temporary cooperative rélationsnips by 
locating the desired partner process via tne data 
dictionary/directory system and activates that process ina 
workstation after insuring that the partner 1S ready. An 
approacn for increasing the speed and recucing the overhead 
by cutting hand shaking procedures to the bone 1S explained 
In (Schneidewind and Dolk 1983). The Second mechanism 
employed is the exchange of data and status and control 
information over established sessions. This syncnronizes 
cooperating processes, the databases they modify and the 
journal entries of exchanged mesSageS in Support of data 
integrity requirements. Security, resource management, and 
System administration also nave manifestations at tne 
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session service level, but have not been included as major 
Session Services mechanisms. 

Network architectures may vary witn regard ee 
implementation structures but, in general, tne functions 
provided are the same. The session Services layer 1S uSually 
one of several layers of control identified witnin an 
architecture. Using a logical architecture model closely 
related to most commercially available arcnitectures is a 
useful way of examining the entire control structure. 

A layered approach to network architecture from the 
International Standards Organization (ISO) defines’ seven 
distinetielayerswof protocol.) (Deitel 1332) 


Physical Layer - This layer handles the mechanical and 


electrical details of the actual physical 
transmission of bit sequences over communication 
lines. 

Data Link Layer - Tnis layer controls the manipulation 


of data packets. It handles tne addressing of 
outgolng packets and the decoding of addresses on 
incoming packets. It detects and possibly corrects 
errors that occur in the Physical Layer. 


Network Layer - This layer controls the switching 
and routing of messages between stations in tne 
network. 


Transport Layer - This layer provides for transter igor 
messages between end users. The users need not be 
concerned with the manner in which reliable and cost 
effective data transfers are achieved. 


Session Layer - Tnis layer provides the means for 
cooperating processes to organize and synchronize 
thelr dialog and manage their data exchange. 


Presentation Layer - This layer resolves differences in 


formats among the various computers, terminals, 
databases, and languages used in a network. 


Application Layer - This layer is the highest layer and 
die 


PrGVv1dese Sch vwucesmulilrecthly fo users. It deals with 
data exactly as it 1s generated by and delivered to 
user processes. This level contains the user- 
specified functions and program controls. 

Mae topology, media, and access procedures for the 
eventual SPLICE system will not be addressed, as they are 
implementation features. Instead, the empnasis will be dlaced 
on design considerations which impact the system 
regulrements. 


The next section will use hierarchical decomposition to 


aid in the definition of the Session Services control 


momctions. 
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[Ills SESSMON SERVICES MaMe PONS 


Each of the major functions will be decomposed into 
their logical pieces and described in more detail. 

The first step 1S to describe the functions that are 
within the scope of the design. No attempt 1s made to 
constrain this step By conforming to current organi Zzatiomeam 
Structure or data processing systems in use. No attempt is 
made to determine the likelihood of automation. This 
functional decomposition is not based on organizational 
attributes, nor does the decomposition address control 
issues at any level. Naming the business functions as 
accurately and consistently as possible helps users’ relate 
to the formalized function descriptions Gur ioe the 
requirements review. At each aggregate level of abstraction, 
an attempt was made to maintain a similar level of detail 
throughout that level. That 1S, the scope, slze, magnitude, 
and relative importance of each module should be 
approximately equal at each level. During the process of 
function definition, the next lower level of tfunctronalive, 
is described in an effort to validate tae level gear 
developed, and to insSure the ability to make accurate 
tradeoff decisions concerning cohesion and coupling issues 
Pacer. The function description consists of a unique 
identifying number, the logical function name, a description 
of the function, and its required input and output. When 
Validating functions with respect to system requirements, it 
is useful to have a nierarchical cnart  Giweeme en tunct looms 


ie: 


avallable to cross-reference the function with its relative 
Beereron among the Eunctions aS a wnole. ‘The data flow 
diagram 1S also a helpful tool to relate the flow of data 
Booed, ene different™ functions. Particularly confusing 
[Meas may also be charted in an effort to clarify tne 
Particular environment or requirement. 

Tne following diagram snows”) the major Og itea] 
components of the session services module: 


1.0 


SESSION 
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Tae Following descriptions Sateen Maagia lever 
functions. Because eacn high level function is sudsequently 
broken into lower level functions, th] Gescriptrons wil 
only include a narrative describing the function performed. 
Tae lower level funetions will tnen be desert ibeo in ee 


detail and inputs ana CUtputs Will bo teow enoe: 


SESSION 
SERVICES 


l= 
ESTABLISH MONITOR CLOSE 
SESSION SESSION SESSION 





RAKE KKKRKEKEKEKKEKRKKEKRKEKRKKKE KKK KKK 


NAME: SESSION SERVICES 
IDENTIEMER: IY 


Establishes, monitors, and closes all sessions on 
the system. It initiates and controls the required 
elo lgleseto bal aliane, functional modules to accomplish tne 
requested task(s), and returns a response and/or 
control to tne user via the TM module upon completion. 
Tnois module 1S capable of controlling multiple sessions 
per uSer. 


ReRRKR KKK KKRKRKKRKRKKR KR KKK KKK KK KKK KKK 


NAME: ESTABLISH SESSION 
TOL N The Le Rei 


Translates a service request from the Terminal 
Management Module (TM) to its required mapping of 
Functional modules to satisfy tne task named in the 
service request. The function also activates the 
Initial Controlling Functional Module (CFM) and _ sets 
Session statuS to indicate an active session, or 
rejects tne session request based on security, or user 
AUENOEL ty  Crileeria- 


i> 


www we KKK KKK KKK KKK KKK KKK KKK 


UBURR EYUATOR, SESS 100 


Maintains cCommUmication with, and passes control 
to each CFM in accordance with the session map. This 
Bum@ettionm  icemtifles additional Gata required for tne 
user to complete a given task pased on tne map of 
functional modules. This function also makes = any 
changes to the functional module map, ana will verify 
SuEputcee trom a CFM for those tasxcs whicn contain fault 
tolerant backup modules. 


RRM KEKK KR KKK KKE EK 


NAME: CLOSE SESSION 
MOENTIFIER: 1.3 


Updates session status to show result of Session 

Complete Message, aids the system in maintaining 

consistency in the session and/or system status during 

interrupt processes, and aids the Recovery Module by 
providing accurate session status information. 

The following data flow diagram is an example of the 

system activity that occurs at the highest level. The data 

flow diagram is most useful to the reader as a verification 


that the system is consistent and logical. It 1S sometimes 


easier to view the system in this chart form. 
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HIGH CEVEt 
DATA FLOw DIAGRAM 


REMOTE LOCAL 
US ti USER 








TERMINAL 
MANAGEMENT 
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LOGICAL 
BUS 


ee 
DATA DICTIONARY 











CONTROLLING 
FUNCTIONAL 
MODULE 


Spec 
FUNCTIONAL SESSION 5 PA rus 


MODULES 


ty 


The next section descrides the lowest level functions. 
Paemeecis level, tne modules will nave suggested logical 
Mipues and outputs identified for later mapping to a low 
level data flow diagram. InputS and outputs have deen 
associated witn their respective sources (origins) and 
destinations (target). The sources and destinations are 
SPLICE modules and CFMs. When either the source or the 
destination 1S a sub-module within tne Session Services 
Module it will be identified by the unique identifier of the 
Sub-module. To later complete tne logical design for the 
specific SPLICE application, the input and output data must 
be quantified. Tne expected level of activity will help to 
size the system and provide necessary input to design 
decisions concerning data base structure as well as module 
determination. 

The decomposition that follows is for the Establisn 


Session function. 


Establisn 
Sesslon 


Determine Initiate 


Reject 
Session 
Request 


Session 
Process 


Map 
Seructure 
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Ure e Wek 


Pe ei 


RE KERR KKK KK KKK REE KEK KREKEE 
DETERMI we WAP OFRUS Tes 


[TE ICATION: | ieee 


JESCREPT ICN: Tnis function deter] Mesias 6 corm. @ Umar 


Structure based on tne taSK request and uSer or system 
NrOV1GOG Paraneters. “9Ine Tap SEE Mestre swe] eee 
of the processes Within a tasSk and tneir relationsaios 
to one anotner. TaSk requests may be Girecteud to a 
specific workstation mailbox by means of a wuUniGgue 
logical name. Tnis information 1S uSed to enter tne 
data dictionary/directory system and retrieve the 
assoclated mapping structure Eom tne reyulrea 
functional modules. 


SOURCE, DESd mie linen, 


INPUT: Session Request Terminal Management Module 
OUTPUT: ‘Task Request Data Dictionary Functionai 
Module 


REKKKKRKKRKRK RK KEKE 


NAME : 


REJECT StsSSstONFRECVUESSs 


[DENTIPVCATION. » lel. 2 


DESCRIPTION: Tnis function receives the oxception status 


from the DD/DS and sends an appropriate response to tne 
Originator Via’ thew. 


SOURCE /DEST Rilo 


INPUT: Task Rejection Data Dictionary func tremal 
Module 


OUTPUT: Session Rejection Terminal Management Module 
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NAME: 


INITIATE SESSION PROCESS 


LDENTIE NEGATION: 2 eles. 5 


DESCRIPTION: This function assigns a unlque identifier to 


the session, initiates a session-data entry whicna 
includes tne map structure, a timestamp of initiation, 
current controlling functional module, etc., flags tne 
controlling functional module as active, “and mosss > 
control via a message to tne local or remote CFM. (Tne 
Natlonal Communication Module will reluy tnis message 


da, 


Svemeedem Oi 1h be 1S destined for a remote CFM. 


Some C/O eol lari ch 


yee 


Peo hema stErucrure Jee leelOnar, EUnctlonal 
“oOduske 
CurPeUT: Controlling 
Pb lOrlark BPoGcaimoOnr csemote CFi4 
Moaule Name 
Mmeomea-GOr0OSITELOnN tnat Follows is for the Montutorc 


Beeeron Function. 


MO tio Tr 
session 


Traverse 
Map 
Structure 


Alter 
Map 
SEPFUCEUrEeE 





Verify 
at 
OU EOU 
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NAMES TRAVERSE MAP STRUCTURE 


BesCRIPTION: This function interprets completion 
Smempue, cext location(s), and/or parameters from active 
Senerolling Functional Modules (CFMs). [It checks tne 
message against the active map and identifies tne next 
CEM to be activated. It removes the activation pointer 
From the current CFM and places it on tne next CFM to 
be initiated by sending a message to the CFM. If tne 
map has been completely traversed, then a completion 
message anceeene  —bLOcation Of output text and/or 
parameterS are sent to tne Terminal Management Module 
| ou ee (Grapnical view of tne possidle process state 
transitions are in Table l on page 21.) This’ module 
also recelves abnormal termination messages trom CFMSs 
wnich nave fault tolerant backup modules and replaces 


messages, 


2U 


tne module oroducing tne Crme@r With a ster laeomome 
noawe. 


SOURCE / OES? Ee. 
SEUNG CEM Completion Message Cone wel lime 


EUnC Elona 
Module (CEM) 


Output Text Location Si 
Control Paranmetes ae 
OUTPUT: Session Completion Message Verminate Session 


Process “(1.3.8 


all 


PROCESO STATE TRANSITIONS 


PO wmeOr CE rlow UR 
EVewe COMPLE PLON 


Mer 
RUNUOUT 













WO WAL. OR 
EVENT WAIT 


DISPATCH 


RUNNING 


Me UME 


SUS PEND 






SUSPEND 






Route 


SUSPEND 


eUS PENDEDU SUF DED 
READY BLOCKED 


POCO VPEDT LONSOR 
EVENT COMPLETION 


TABLE 2 
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kk aR KKK KR KKK KKK KKK KKK KKK KKK KK 
NACIED “SiG Gok avlev’ © leo as 
LOENTIE PCALTION: “lever 


DESCRKIPTIUN: Tois function is responsiodl]e fOr aye ore ee 
made to tne functional map associated WiShiawcask eee 
can vde received from the active Control iiigeeunc cic em 
module, tne fault tolerant Output Yerificaeron nocum. 
(1.2.3) or the user. The cata May COnNSISE Of Gareiwae 
modules that are Outside of tne normal map structure, 
requests for additional information, Gr Gataydeser moma. 
interference situations caused by access of SfAared 
rescurces. 


SOURCE /DESTINA Teg 


INPUT:EFM Call Validate Request CEM 
User Message Terminal Management 
OUTPUT: Map Alteration Messace Traverse Map 
Structure (lo 238 
EM Call Validation Response CEM 


Reem KKK KKK KKK KKK KKK KR RRR KKK KK 


NAME? (VERDE Y CEM SOU newt 
LUENTIE DER. elie. 


DESCKIPTION: This function verifies output £rom Contra mean. 
Functional Modules prior to control being transferred 
From =ne Cri. [It compares the output data tmat “aia 
resulted from tne CEM against a prescribed valid outdut 
Standard tiiat nas been develovded for the moduls. ‘ne 
output will eltner matcn, meaning tnat control can ve 
passed because the module arrived at valid data, or tne 
output will not pe considered valid, meaning tne module 
nas failed. waen tne module nas failed to provide valida 
data, tne name of tne logical fault tolerant module 
replacement 1S sent to Alter Map Structure and tne 
replacement module will be executed. 


SUURCE/DESTINATION 


ENCPOUT> Clim Outeur Chm 
OUTPUT: Replacement Module Name Alter Map Structure 
Clee reo) 
iiessage to User Terminal Management 
LQrOrR  NGthrica=lon CEM 


1ne decomposition that follows is for the Close Session 


mS 


meoction. 
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Pee tan INATE SESSION PRUCESS 
Meri lTER: 1.3.1 


Pepe ere TON: This function is responsible for completing tuc 


session-status data entry for a completed Nap 
Seructure, and Signifying tne end of a session. ine 
"active" flags will pe removed from the last active 


Seep weimestamped for termination, and an appropriate 

message sent to the TM module indicating reason for 

Meeainmetlon and location Of any existing output. 
SCURCE/7 DES: I NATION 


INPUT: Map Complete Message Traverse Map Structure 


(else. © ale) 
STRUT: Output Location TM module 
Termination Message TM module 
RHKEKKRKHRKRKKEKRKKREKKKKKRKEKREKRKEREER 
NAME? ASSIST INTERRUPT PROCESS 
Meme rie TER: 1.3.2 
Prec RIPTION: Tas PUMGtvom swt) L resolve interrupts 
Originating wnen the active controlling functional 


moagule requires additional data concerning user desires 
or system requirements. 


SOURCE/DESTINATION 


INPUT: CFM Request Set 
User Request TM module 
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CEs xuquest Len 


emma K KKK 

Namie ASS loT “REVOVERY Priors ss 

[DENTIEUGAT LON2 Sle 

DESCRIP Tamer: nis Lunction 3163S CAS sScovery Od treme eer 
providing current Status Of “abs 2s57 00s Visenee aaa 
The cvstart and/or recovery Us Ve0me ol led ene lr iy ee 


Eno | Moaule. 


SVURCE BEST LATION 


DBO: Seatls eucdees & RMS cue 
CUTPUT: Status response RM module 
Tne following cnart snowS a summary of possible 


commands tne Session S@nrVvicesmto71 so 
INITIALS 

ACCEPT 

TERMINATE 


SEo 51 On 


SEND 
RECEIVE 


SESSITON=-DATA-UNIT 


TERMINATE 


INTERRUP’ 
TERMINATE 


SUSSTON-jINVERACYT LON-UNTIT 


HEC APO. 
RECOVER 


PROCESS RECOV ER sauce: 


SCrtta [ 
RECOVER 


PROCESS=COMMT TE eae 


‘e) 
CANCEL } SESS LON =CUARAN TEENIE Nee: 


Tne following data flow cnart 15 an Gxample Jor eege 
System activity tnat occurs at the lower level. It 1s useful 


octn as a cifferent, o1ctorial view Of “Smeeemeo oon eae 
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meee cOOl wnen maoping tne data to the functions. 


OW ioe y iL 
DATA FLOW DIAGRAM 


To lel 
DETERMINE MAP 
STRUCTURE 
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LV. SESSIlUs SERV ICES eee 


The next step 1S to define Che a eawse ee. 2 oa nee 
scope of tne system. .t Elrst, ENlS 1S 3cems ey eS ee oe 
view to gata only, 19nm0rliny any PSelatl On mie eee ete noe 
BecauS2 Many UWISCONCSYCLONS wbOut Jor ae See Coo eee 
exist anu Way detract from "Ene CoGu he cee -ac oe eeae 
Several Srontiicane terms assoclated wictn Coe 


interpretations of data used in €91S de6eumene are" deniges 


pelow: 

DATA CLASS - a collection of data uSed to describe an 
entity wnicn is easily descripbable, readily comprenhendible 
and meaningful (witnin tne system boundaries), past tne 


9o0int of just being a collection of data elements. Usually 
tney can be uniquely identified, and have unique data 
elements associated with them. Basically, two types are 
distinguisnable: objects and concepts. 


OBJECT - a particular occurrence of a4 data Class vam nee 
exlsts, and 1S capable of being sensed. 

CONCEPT - an effort or detion in tia real eworld sed: 
example of some typical concepts mignt make tne distinction 
Clearer. A “bank account" may well be a concept data class. 
It 1S uniquely detined dy an account number, has meaning 
Witnin the oankiny inuuStry, Yet you Cannot tovcn “it cuees 
exists merely aS an agreement petween the customer and tne 
bank. It can b® represented or relerrea to Sita 11st igs om 
account status, or inquiry, but Cannot ove seen or Sensed. 


INDICATIVE KEY - the attribute wnichn enables an object 
Or concept witnin a data Glass to be Unigquewyeoen ter ie 
indicative Key points to one and only One occurrence of a 
data class. 


AREF KEY - an attribute used to show a relationsnip of 
one data class to another data class. Tne physical 


implementation may appear as a link record or pointer. 


Each data class is described in a form consisting of a 


UWata description, <xcy elements, and relationsnips to other 


2/ 


Pee Classes. Selection of tne data class name snould owe 
Semielaee’e Wien Ehe USage Witnin tne sySten seing modelos. 
mete is, Cne users of tne system snould not ne forced to 
Smee Ghelr mormal vocabulary. Tae iagentificaution of the 
mewemeeare Sl prul later in tne development of tne ootimu.n 


@ieeceeStruccure. 

Miemcerimichonm OL caw data for tne systean 1s completed 
wnen this step 1S completed. Furtner refinements- and 
Supsequent information may require any of the steps to ove 


re-evaluated and altered. 


DaTA CLASS DESCRIPTIONS 
a a ee eee eae ee ea ee 


WAME: SESSION - DeScribes the time frame that represents a 
user requesting a task from the SPLICE system and 
recelving a response to tne Eequest. Tne 
peginning 1S marked by tne session Services 
Module after it nas received clearance for a 
particular user for a opdarticular Pune t Lona | 
module. Tne end 1s marked by the Session Services 
Module when an error has forced an abend status 
or tne functional map nas pveen completed, = anc 
control is returned to the user via tne Terminal 
Management Module. 


POE MEN To: 


Session Number (Indicative xey) 

Timestamp 

PunetLonale. lap 

Conerokling, Eunctlonal Modules 

Stmrmemercommcaorling FuncElOnal Modules 

User Identifier (XREF to User) 

Terminal Identifier (XREF to Mailbox) 

Service Request Code (XREF to Tasx ) 

Status Code (Inactive, suspend, resume, I[/0 
Wodteere ECs.) 
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a ee ee ee ae ae ae ae ae ae a ee ee ee ee 


Wari © CEuwer = yeserloeS GiCM JOS Sina esis ey eee 
aliows tne user to reyuest From any wor< Stacivon 
howe Cie Sys Eo ne LC ooo gigs] Ce eon a ee oe 
PUie eLegae Module, calleu a Contre line 
Funccional <iouule, OF eae yer eee 
Several mouules cOontalmwmr, a CONG Bo lr ing 


runetional Nowule ond Chesca e eee 
Boece Noe: 


SL2EVICe huyuvest Code sine eae yo 
User Autnority Required 

Logical Name of rodule 

Logical” Poecaituern 

Poy S1Ga le lOee ere 

Paraneter Specification 


wa aK KKK KKK KKK KR KKK KKK KKK 


NAME: MALLBOX - A Ne tnod Oe uniquely LOSheEl Ey ame 
repositories of data from deferred tasks. I[t also 
1dentiries tne nature of tne service reyguestec 
for those users with multiple mailboxes. 


ELLMENTS ; 


Mailbox tuumber (Indicative key) 
Command Location 

Logical Address 

Pnysical Address 

Hardware Configuration 
Clearance Level 

Constraints 


Rae KK KKK KKK KKK KKK KKK KK KKK KK KKK KKK 


NAMES USER - A Dencon Or group of persons we are 
authorized access to tne SPLICE system. 


EC enn dels 


PasSword ({indicativesce | 

Log-on 

User Name 

Parent Command 

AUGNOELZatroneteve. 

Terminal Restrictions (XREF to ‘*iailbox) 
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V. MAPPING OF DATA TO FUNCTIONS 





[Tne logical design, Paseo On fUumMeEloOn and data was 
Me@esented in the previous section. future work in tnis area 
PeemeeernvyOoLVe Mapping tne data to the functions, tnat is, we 
wemeeedetermine which functions use wnicn uata. 

Giese data dre categorized with respect to the role they 
Meeayetor that function as well. Dawomie diese va, ERLGger tha = 
@emises the function to occur; it can be input from 9 anothner 
Mmaigerron, Or outside source; it can be input from the data 
repository; 1t can be an output whicn triggerS another 
meee On,; it Can be output to a data repository; or it can 
be output to another function or outside destination. 

After data nave been mapped _ to tne Paty iddal 
functions, a determination 1S made of what transformations 
occur in the system 1S made. A transformation 1S an action 
tnat changes the input data and creates or hnelps to create 
Gemeeomtouct. Using input/output data defined in the function 
description, values for the quantities of eacn particular 
Input and output can be used to determine tne numbers of 
occurrences of tnese transactions. The quantities may 
address data class apstractions; therefore, tne data 
dictionary may have to be used to cross reference data 
elements tnat are at tne particular level identified in tne 
transformations. 

Tnis information can be used to grapn the number of 
occurrences of transforms and relate this information to tne 


required Gata relationships. Using tnis Sean, tne 
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transforsations tnat most frequently occur within the system 
ade lucnMtiiivu. Tnis graph can then be Wsedmpordec pam. quar 


lo,ical data relationships to implement. 


Bt 


Va ob oomON SERVICES INTERFACES 


The Session Services Module nas no interface external 
to the SPLICE system. The user and other systems only access 
the session services module via other SPLICE modules. There 
are major interfaces wnich must be defined within the SPLICE 
system. The following interfaces are addressed on a logical 
basis without identifying the actual implementation details: 


SESSION SERVICES TO TERMINAL MANAGEMENT MODULE 

Rather than communicate directly with user terminals, 
the functionality 1S separated between Session Services and 
Terminal Management. The end user always communicates with 
the Terminal Management Module and the Terminal Management 
Module always communicates with Session Services or the 
user. The TM sends session requests from a particular 
mailbox or interactive user to Session Services. The 1M 
recelves the completion message, the output location, the 
rejection message, and the information request message from 
session services. The TM will provide all necessary message 
editing, screen management and virtual terminal operating 
functions. 


SESSION SERVICES TO RECOVERY MODULE 

Session Services is a support module to the Recovery 
Module. When tne Recovery Module requires data concerning 
the current or recoverable state of all or any session, the 
request will be addressed to Session Services. Session 
Services will access the required data and forward them to 
the Recovery Module. No recovery logic 1S contained in tne 
Session Services Module. 


SS ee ee 


When Session Services requires data concerning user 
authority, task Security level, task mapping structures, 
data structures, or functional module relationships, it will 
request that data from the Data Dictionary/Directory. 


SeoolON SERVICES TO NATIONAL COMMUNICATION MODULE 

During a session, the control is passed to the 
Semtrolling Buneel ona! Modules via_ the logical bus 
mechanism. If the logical name refers to a remote module 
then it 1S picked up by the National Communication Module 
(NC) and initiated for transmission on the DDN. The NC 
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Module will convert LAN protocol to Defense Data Network 
protocol and vice versa, enabling session services to rely 
only on the local LAN protocol. 


SESSION SERVICES TO LOCAL COMMUNICATION MODULE 

During a session, control is passed to the Controlling 
Functional Module via the logical bus mechanism. PE ee ae 
logical name relates to a module contained in the LAN, then 
it is picked up by the Local Communication Module and 
inlet lated. 


SEOoTLONBSERVICES 19) SESSION SiATE DATA 

Session Services is the only module able to access 
sesslon state data. Tne Session Services Module will 
maintain state information in its own file. These data 
Should be structured so that no other module may access 
them, and more critically, alter them. 


SESSION SERVICES TO FUNCTIONAL MODULES 

There is no interface between Session Services. and 
functional modules, other than a Controlling Functional 
Module. All called functional modules interface solely with 
the CFM. 


In general the interfaces do not require any additional 
information to be added to the LAN message format presented 
in (Schneidewind, 1982). The data that are contained in the 


LAN message format include: 


MESSAGE TYPE 
DATE AND TIME 
DESTINATION ADDRESS 
DESTINATION LOGICAL ADDRESS 
DESTINATION PHYSICAL ADDRESS 
SOURCE ADDRESS 
SOURCE LOGICAL ADDRESS 
SOURCE PHYSICAL ADDRESS 
NUMBER OF FRAGMENTS 
MESSAGE NUMBER 
FRAGMENT NUMBER 
ACKNOWLEDGEMENT FRAGMENT NUMBER 
DATA LENGTH 
SERVICE RECURS T  €OpE 
DATA 
ERRORS CHECK 
FLAGS 
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All fields are f1 
ixed length exce 
pt for the field 
called 


DATA. 
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VII. DESIGN RECOMMENDATIONS 
Our major design recommendation concerns the 
implementation of fault tolerant techniques, which is 
covered in some detail because of the general lack of 
awareness concerning fault tolerant methods. The  otner 
recommendations addresS possible problem areas related to 


tne nature of the application environment. 


A. FAULT TOLERANCE 

The notion of incorporating a means for tolerating 
faults in order to improve computer system reliability is 
well established. Because of the usual multiple meanings 
of data processing terms, we will attempt to define several 
terms. Fault tolerance 1s a term deScribing a system capable 
of coping with faults without a requirement for manual 
intervention. Fault prevention, a Similar concept, avoids 
potential faults by detecting and eliminating them prior to 
operating the system. Once tne syStem 1S operational, fault 
tolerance,if 1t exists, begins. The SPLICE session services 
module should employ fault tolerance to improve reliability. 

For a system to be fault tolerant, 1t must be able to: 
Getect errors, assess and confine the damage, and repair or 
recover from the error without forcing manual intervention. 
Detection methods are most abundant. Assessing, confining, 
and recovering methods are not well defined nor readily 
avallable. 

Unmastered complexity at any level increases the 
possibility of a fault occurring. I1t€ 1S hignly Wome, seas e 
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the SPLICE system will ever be fault free. A major part of 
the complexity in SPLICE will be implemented in software. 
Therefore, software developers should seek not to design 
Meemereect, Crror free” software, but rather attempt to 
mmeoumae reliable fault tolerant techniques for SPLICE in all 
modules. | 

Any definition of tne reliability of a system must 
involve distinguishing between acceptable and unacceptable 
benavior of the system. There must be some method to 
distinguish between unsatisfactory benavior which is a 
consequence of user misunderstanding’ and unacceptable 
behavior due to deficiencies in the system itself. The 
system specification should provide that mecnanism. 

Ideally, a specification should be consistent, 
authoritative and so complete that the behavior of the 
system is defined for all possible input = and output 
sequences. In each circumstance where this iS not. so, 
acceptable benavior cannot be distinguished from 
unacceptable behavior. Regardless of the specification, only 
two concepts are essential to understand the causes of 
failure: (1) an event (state) which should not have occurred 
and (2) a condition (state) which should not have arisen. 
Internally, these are usually referred to aS erroneous 
transitions and erroneous”) states. If either of these 
internal situations exists, then it follows that the system 


has had a component or design failure. 
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"An erroneous transition of a system 1S an internal state 
transition to whicn subsequent failure could be attributed. 
Specifically, there must exist "4 (possible = sequencc mon 
interactions which would, in the absence of corrective 
act ron from the system, lead to a system failure 
attributable to the erroneous transition." 

"An erroneous state of a system 1S an internal state 
wnich could lead to a failure by a sequence of valid 
transitions. Specifically, there must exist a possible 
Sequence of interactions which would, in the absence of 
corrective action by the system and in the absence of 


erroneous Eransierons lead from the erroneous state to a 


system failure." (Anderson and Lee, 1983) 

Design faults are unpredictable and unexpected. 
Unanticipated errors are the result. Experience from 
prevlous, identical or Similar faults is usually not 


helpful in resolving the design fault. 

If these ideas are acceptable, then it 1s not difficult 
to determine why a major portion of the effort in fault 
tolerance has been aimed at component failure to date. To 
illustrate the point, make this trivial comparison of an 
easy component failure and an easy design failure: 

COMPONENT - A diode fails, causing an open circuit. 

[It was predictable since diodes only last so many 
hours in certain environments. The result of a 
continually open circuit is predictable and can be 
anticipated. It is repaired in the same manner as 
tne last diode failure. 

DESIGN - A logic circuit fails to produce the desired 

results. The desired results are to exchange the 


values of variable Ai and Aj without using. an 


Sr 


— 


auxiliary variable. 


The algorithm used: 


Al:= Aj 


An obvious design failure causes the value Ai to be 
Kost. 


EemecOLLect the algorithm the following adjustment may 
be made: 


Ai := Ai - Aj 
Aj := Aj + Ai 
Ai := Aj - Al 
The problem did not go away; it just changed and became 
more difficult to find. Now, it works for most cases; 
however, this algorithm will fail when 1 = j. The resultant 
error may not always be the same. The repair of the error 
May require different procedures for each error, therefore, 
the experience of past identical or similar failures may not 
be useful. 

Techniques such as top down development, structured 
programming, step-wise refinement, and information hiding 
all embrace the principle of divide and (nope to) conquer. 

Some of the problems of software-oriented fault 
tolerance are unique to the errors found in software design. 
There have been two methods suggested for providing software 
with fault tolerant characteristics which address’ those 
unique qualities which make software fault tolerance so 
difficult. The methods are called: "Recovery block scheme", 
and "N-version programming". Both operate under the 
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assumption that, despite tne use of fault prevention 
techniques, any complex software system will always contain 
residual faults when placed in Service. 

Tne recovery block scheme was designed as a method to 
provide fault tolerant capabilities to sequential programs. 
The application module is called the primary module and is 
defined as a non-redundant software module which has been 
designed and implemented to satisfy the authorizing 
specification. 

The first stage of the process 1S to detect when an 
error arises during the execution of the "primary module." 
Since tne primary module has been debugged and tested as 
much aS practicable, the module may run several times 
without any error conditions. There are advantages and 
disadvantages to placing an error detector within the code 


itself. The error detection module should be Separate and 


executed immediately after the execution of the "primary 
module," before any data are transferred and used in a 
subsequent module. This “acceptance test" consists of a 


sequence of statements which will ralSe an exception if the 
State of the system is not acceptable. The primary module 
will have failed if any exception is raised. 

The second stage is to assess the damage and repair or 
recover. This function will require a recovery point 
mechanism to prevent rerun of entire modules or groups of 
modules. Therefore, at the beginning of each primary module, 
there will be a sequence of statements, or some method of 
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indicating the status of the machine environment. Various 
methods are 1n wide use today and may be applied. When the 
error occurs and is detected by the "acceptance test," there 
must be an avallable alternate module to process. If we were 
to recover and repeat the primary module under the same 
conditions, we would expect the error to recur and we would 
Mave an endless cycle of execution. The alternate modules 
are logically capable of producing the required output as 
defined by the "“acceptance test." They may be less 
efficient with respect to memory and/or speed, however, or 
be designed ina less complicated fashion. Regardless of 
thelr weaknesses, their strength is that they have less 
probability of design error. Perhaps several alternate 
modules are developed, each less complicated than the 
previous. This alternate module 1s, in fact, built-in 
redundancy and reflects the degree of reliability required 
of the system. The alternate modules are invoked only if an 
SaeOor OCCUrSs, thus minimizing the overhead. Software 
monitors can be used to record activation occurrences of 
these alternate modules. Run time overhead is incurred for 
each recovery point established and for each call to the 
acceptance test module. The recovery block logic appears as: 

ESTABLISH RECOVERY POINT 

EXECUTE PRIMARY MODULE 

APPLY ACCEPTANCE TEST TO RESULT 

INVOKE ALTERNATE MODULE IF FAILURE EXISTS 

APPLY ACCEPTANCE TEST TO RESULT 


INVOKE ALTERNATE MODULE IF FAILURE EXISTS 


The usual syntax associated with the scheme is: 
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ENSURE <acceptance test criteria> 
BY <primary module name> 
ELSE BY <alternate module #1> 
ELSE BY <alternate module #2> 
ELSE ERROR 
Tnese blocks can be nested and do not impose 
constraints on the programming style or the methodology 
being used. Tney are compatible witn structured programming 
techniques and high level languages. 
In a sort application, the fault tolerant recovery 
block might appear as: 
ENSURE A[jt+tl]) >= A{j] for j=1,2,. . -n-l 
BY Sort A using quilcksore 
ELSE BY Sort A using shell sort 
ELSE BY Sort A using insertion sort 
ELSE ERROR 
Where quicksort 1s a time-efficient, slick, compactly- 
coded module; shell sort is less efficient, but easier to 
visualize and less prone to deSign error; and insertion sort 
is a simple brute-force type of sort routine. 
Fail soft approaches also use this technique by naving 
each alternate module provide some reduced service or a 
subset of the required output. The following is an example 
of a disk-to-memory transfer function which is being 
gracefully degraded: 
ENSURE consistency of disk transfer queue 
BY enter request in optimal queue position 
ELSE BY enter request at end of each queue 
ELSE BY send warning message “request ignored' 
ELSE ERROR 
While the above example may cause problems for the 
program requesting the transfer, tne rest of the system can 


proceed without disruption. 
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@ontreol ~rlow of tne recovery process can be directly 
Supported by microcode, or by the use of special purpose 
instructions whicn are tailored to suit recovery block 
schemes. The Anderson and Kerr report describes an 
experimental architecture which provides this support in a 
recovery cache mechanism. 

So far, it has been assumed that exceptions occurring 
during the execution of a recovery block program will result 
in backward error recovery and a transfer of control to the 
next alternate module. 

There 1S, however, nothing to prevent a forward error 
recovery technique within a module of a recovery block. An 
application of this concept might be used in the detection 
of an underflow occurrence. An error handler could insert 
the lowest value number used in the machine and continue to 
process; then flag the result with a note to the user that 
the substitution was made. In this case, it iS more 
efficient than finding a recovery point and running an 
alternate module. Other situations exist which favor forward 
error recovery as well. 

The recovery block scheme 1S conceptually simple. Tne 
implementation may not be as simple. Alternate modules 
require extra coding and require more complicated module 
interfaces. This added complexity has not been quantifiable 
to date. This is true because of the lack of total testing 
results and the lack of use in multiple application areas. 
Because alternate modules are independent of one another, 
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the implementation of multiple alternate modules 1S not much 
more difficult than just one alternate module, if previous 
modules exist. This could be very expensive if all modules 
were developed from scratch; therefore, a good source of 
alternate modules 1S found in the prior versions of a 
module. For example, as updated replacement modules (with 
optimized features, or refined functions) are ready to be 
implemented, the previous module may be used as the first 
alternate. 

The acceptance teSt procedure adds a dimension of 
complexity that 1S mot present in non-fault tolerant 
Systems, although, for every set of alternate and primary 
modules, thiS acceptance test need only be designed and 
implemented once. In the SPLICE application, this module 
should not be unacceptably large or complex. It should be 
noted that SPLICE will use a Tandem Computer system which is 
designed to provide redundant hardware and software modules 
For all major Eunctions. 

The second method for implementing software fault 
toleration 1S conceptually simpler. The N-Version approacn 
to fault tolerance has N versions, where N 1S greater than 
1, of independently designed code which satisfies a_ single 
Specification. All the versions are executed and all the 
results are compared. The correct (majority) response 1S 
sent to its destination while the erroneous responses, if 


they exist, are ignored. 
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The implementation of the scheme requires a driver 
program to invoke eacn version, collect each response, 
compare the results, and determine the correct response. 
Bach version operates atomically and uses the same input 
space, so the driver must synchronize the execution of 
versions. The originators of this approach, (Chen and 
Avizienis, 1981), use a handshake method with "wait" and 
"send" primitives to insure that only one version at a time 
is running. This scheme prevents realizing the advantages of 
Pipelining, or parallel processing. It also requires a 
timeout detection capability to prevent infinite loops. 
An advantage of the N-version technique is that damage 
assessment would not have to be done at all, and error 
recovery is done by simply ignoring the erroneous answer. An 
obvious disadvantage on the other hand is the overhead of 
atomically executing each version with the same input space, 
and executing a voting check to obtain a single result. 

There are few, if any, theoretical reasons for not 
adopting fault tolerance technigues. It seems that the real 
factors preventing widespread acceptance are: 

O Education: Lack of courses, books, and quantifiable 
evidence of improved reliability, make it a 
difficult idea to sell to managers. 

o Psychological: Adopting these schemes is, in some 
way, admitting the existence of design faults. 
Therefore, the designers and programmers do not 
have motivation to persuade the managers. 

fe) Cost: It 1S perceived, by project managers, aS an 

additional cost without additional functionality. 
Without the necessary motivation, they are unable 
or unwilling to justify the development Or 


runtime overhead involved. 
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Since a great deal of money will be spent on SPLICE 
software (development and maintenance), producing fault 
tolerant software may be the most advantageous approach from 
a systems life cycle cost perspective. Again, we note that 
hardware fault tolerance 1s provided by the SPLICE Tandem 
system. However, this feature is of little help, 1f there 
are errors in applications software. 

Be Jeopardizing Coupling and Cohesion Principles 

A designer should not attempt to excessively enlarge 
functional modules in an effort to reduce overhead. This 
must be a carefully considered option. If multiple functions 
are combined or extra data are passed to prevent another 
call, then the modular characteristics begin to deteriorate. 
This may result ina very expensive and time consuming 
maintenance portion of the life cycle. Control ligg 
functional modules should be capable of coordinating an 
entire transaction. For a single controlling module _ to 
coordinate an entire transaction, i1t 1S required that it 
contain all logic necessary to perform that transaction. 
System designs which dictate that coded modules be as 
cohesive as practical and that coupling interfaces be kept 
Simple, are usually easier to maintain. It is far better, 
at least in the design phase, to split out functions in the 
widest pattern. More breadth in design eases the task of 
maintaining coupling and cohesion principles, while not 
adversely impacting the implementation. If, for example, 


after sizing the transactions, it appears that control 
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cannot be achieved efficiently, it 1s possible to 
Systematically combine the modules witn the least negative 
impact and the most benefit. 
c. Use of ADA Program Unit Specifications 

The use of ADA as a program design language would serve 
to enhance the SPLICE software deSign process. The use of 
ADA program unit specifications during design can be 
implemented in either ADA or Pascal easily. Additionally, 
this systematic approach, will allow this design to 
interface more easily with future DOD supported projects in 
the logistics environment. The ADA Program Support 
Environment (APSE) could have a long learning period 
associated with it. To begin using it now would improve 
FMSO's long term position with respect to the Navy's support 
of DOD policy and, at the same time, provide a= good 
environment in which to learn it with relatively low. risk. 
APSE would provide configuration control of the functional 


allocation of each program unit. 


BA Naming of Modules 

The naming of unique modules will be difficult to 
achieve because of the widespread adoption of local unique 
programs at each of the stock points. Many stock points have 
personalized the reorder process, the inventory process, and 
many management reports. In some stock points, local unique 
programs form the basis of the MIS used, instead of the FMSO 
Provided UADPS-SP. Local programs may nave the same names 
as modules at another stock point; they may also have tne 
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Same name and function as a module from UADPS-SP. Because 
most stock points believe they have unique requirements or 
because the wait to get requested UADPS-SP ennancements is 
excessively long, tney have created “aunumbpersoteiece ) un aie 
programs that enhance UADPS-SP or in some cases replace it. 
Transaction Item Reporting (TIR) notices from the stock 
point to the ICPs for ICP-conerolleae canis s iam) come 
with stock point local-unique programs. 

This is a critical problem to solve before the design 
of Session Services or any other module goes too far. If the 
local unique programs cannot be standardized for all stock 
points, or cannot be placed ina global library with unique 
names and parameters identified, the entire level of control 
and ability to share data and processes envisioned by SPLICE 


proponents 1S at risk. 
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Vit SUMMARY 


The Session Services Module should contain functions as 
described in section III with the the data described in 
section IV aS a support structure. The interfaces described 
In section VI must be kept in mind during the detail design 
phase of the project.The major design recommendation offered 
in this paper 1S the fault tolerant concept. Design 
recommendations to prevent large modules which hinder the 
coupling and cohesion characteristics of modules and the use 
of ADA program unit specifications are mentioned because the 
SPLICE environment may be well served by their use. The 
recommendation to standardize the local unique program names 
is discussed in an effort to prevent the serious’ situation 
that would result if this aspect of the SPLICE project were 
ignored. The stock points which will be served by this 
system have a long history of addressing local requirements 
with locally designed and developed software whicn 
interfaces with FMSO-provided software. All of the stock 
point requirements must be examined carefully and a decision 
that 1S mutually agreeable between deSigners and uSers must 
be made concerning what parts are to be standard = and 
unmodified, and which parts are to be changed by local 
adaptations. The eventual use or misuse of the system could 


be determined by this decision. 
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